iT邦幫忙

第 12 屆 iThome 鐵人賽

DAY 3
1
AI & Data

資料工程師修煉之路系列 第 3

[Day 3] Reliable, Scalable, and Maintainable Application (2)

  • 分享至 

  • xImage
  •  

接續 Day 2 內容

Scalable (可擴充的)

數據系統現在 Reliable 不代表未來也是 Reliable,系統會進步,

這裡討論的 Scalble 是我們有什麼選項去應對未來的成長如何因應額外的流量

比如 10,000 concurrent user 進步到 100,000 concurrent user,或者未來要處理的資料比現在大的情況。

Load Parameter

就是描述系統的關鍵負載指標 (很多東西真的超難用中文講- -),有了這個指標後才能思考成長的策略 (load paremter 變 2 倍時怎辦),

load parameter 會依各系統不同而有不同的指標,例如 網路服務是 每秒查詢次數 (request per seconds) 、聊天室是 同時在線人數、資料庫是 每秒寫入、讀取的次數 等等。

書中使用 Twitter 在 2012 年 11 月的演講 來說明,Twitter 有 2 個主要的操作:

  • 貼文
    • 4.6k request/sec 或 平均 12k request/sec 每個貼文
  • 首頁 timeline
    • 300k request/sec

他們主要的挑戰是如何達成 fan-out ,就是名人貼文後,所有的追蹤者的 首頁 timeline 都要有這篇貼文,

fan-out 是從電機工程來的,用來描述一個邏輯閘的 output 到另一個閘當 input 的量,output 需要滿足且能導向所有連接的 input。

他們有 2 個方法來實現:

  1. 用 SQL 查詢

    SELECT tweets.*, users.* FROM tweets
    JOIN users ON tweets.sender_id = users.id JOIN follows ON follows.followee_id = users.id WHERE follows.follower_id = current_user
    

    figure_1-2

  2. 維護每個 user 的首頁 timeline chche

    figure_1-3

Twitter 一開始是使用方法 1,但在 300k reads/sec 的情況下方法 1 就越來越慢了,方法 2 好一點,讀取首頁 timeline 的事變的簡單了,瓶頸就在寫入首頁 timeline cache 這一端了,

若 user 的追蹤者少,首頁 timeline cache 很快就寫完,但當某個 user 的追蹤者爆炸多時,例如 3 千萬追蹤者,Twitter 若想在 x 秒內讓追蹤者看到這篇貼文就有難度了,

所以 Twitter 的關鍵 load parameter 就是 fan-out 的量。

前公司在設計新聞推薦系統時,是採用 fan-out on read 的概念,我們一樣要確保新發佈的新聞要送給符合的 user 看,但我們是在推薦行為發生時才做完計算並做快取,而不是先建立好每個人的新聞推薦列表,我們的 load parameter 是 QPS。

Performance

有了 load paremter 後再來就是要如何衡量 Performance (執行效率) 了,這裡通常會問 2 個簡單的問題:

  • 當你增加 load paremeter 時若系統資源 (CPU, memory etc..) 保持不變,系統的哪些 performance 會被影響?
  • 當你增加 load paremeter 時若 performance 保持不變,系統資源會如何被影響?

常用的的 performance 指標就是 response time,就是在送出 request 到接收 response 的時間差。

figure_1-4

上圖為 response time 的示意圖,可以看到大部份的 response time 都很低,但有幾個 outlier 讓 response time 變超長,這發生原因可能又是一脫拉庫了,前一天講的各種錯誤情況、 TCP 連線滿載或機器的物理限制等等都有可能讓 outlier 的 response time 變長,

response time 對 user 的最直接影響就是使用觀感,尤其現在人越來越沒有耐心了。

通常在觀察 response time 時我們會用 percentile (百分位) 來衡量,而不會看 mean (平均),平均很容易受 outliar 值影響,常用的 percentile 是 P50, P90, P95, P99,舉例來說 P50 2.75 ms,代表有一半的 request 是在 2.75 ms 內回覆,

下圖是某公司 API reponse time 的 percentile 數字:

figure_grafana

可以看到 P99 有一個 request 衝到 一秒,P50, P90 都很低。

依公司或系統的不同,追逐的 percentile 目標就不一樣,像 Amazon 看的是 P99.9,然後我們團隊是 P99 要低於 1 秒。


關於 response time 還有個很重要的一點是要做到 dependency 隔離,如下圖,只要有一個 request 的 response time 特別長,整體的 response 的時間就拉長了,前公司是用 Hystrix 來分離我們的 backend request。

figure_1-5

Scaling up 和 Scaling out

Scalable 最重要的問題就是:當 load parameter 增加時如何保持好的 performance?

工程師常簡單的一分為二成 Scaling up (垂直擴充,加大機器) 和 Scaling out (水平擴充,都小機器),實務上來看,最好的方式依然是混合版,用有點強度的機器跑服務。

若能用一台 (Scaling up) 就能搞定的需求何必一開始就往 Sacling out 的方向去架構系統呢?

無狀態分散式運算是現在許多數據系統的標配,本系列之路的後續章節將會介紹這些技術,除了幫助工程師更方便的設計 Scaling out 外,更能簡單的達到 Maintainable (可維護的)。

Maintainable (可維護的)

工程師都喜歡開發新系統,而沒這麼喜歡維護原有系統,我曾聽過一種系統開發循環:

工程師快速的寫完新系統 -> 另一批工程師接手維護 -> 覺得技術債太多越來越難以維護 -> crash -> 規劃 v2.0 新系統 -> 工程師快速的寫完新系統

工程師最多的時間都是在維護原有系統,無論你喜不喜歡,當你接手時你就應該跟隨你自己的紀律,把 code 寫好、新功能寫好、測試寫好,保持系統的程式處在 Maintainable 狀態,讓未來的其他工程師不會想拿刀砍你。(但如果是 legacy 系統就算了,這真的該改版!)

再來 3 個軟體開發設計原則

前面提到的 Reliable, Scalable 或許沒這麼容易達成,但我們在 Maintainable 中有 3 個軟體開發設計原則我們可以放在心上。

Operability (可操作的):Making Life Easy for Operations

好的維運單位能保持系統執行的圓滑,以下列個幾點我覺得重要的點:

  • 監測系統和能讓系統快速從不正常的狀態中恢復
  • 設計好的部署、開發流程,還有好的設定檔管理等等
  • 保持軟體更新狀態(尤其是 Security 相關的更新)
  • 維護清楚的系統文件

Simplicity (簡單的):Managing Complexity

直接推薦看另一本書 Clean Code,工程師沒看過這本就慘了。

Evolvability (具有進化能力):Making Change Easy

書中針對數據系統的 Agile (敏捷) 能力給它了 evolvability 這個形容詞,其實就是要做到敏捷開發,

數據系統怎麼做到敏捷開發呢?我們可以試想稍早講的 Twitter 例子,要如何從 方法1 進化到 方法2

這本書後面就是在講這些數據系統、工具背後使用的技術,讓大型數據系統更易於迭代,

例如用 document 的方式儲存 資料能讓你頻繁的變更 Schema。

總結

最概念性的東西講完了,數據系統要完全符合 reliable, scalable 和 maintainable 是條不簡單的路,

希望看完能把這 3 點放在心上,不管是自己寫或用別人的工具都能觀察學習囉!


上一篇
[Day 2] Reliable, Scalable, and Maintainable Application (1)
下一篇
[Day 4] Data Model (1) - Relational Model and Document Model
系列文
資料工程師修煉之路30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言